Developing the first coinflow app, step 2
In Developing the first coinflow app, step 1, a very basic IRC-like interface is described, which can be built relatively simply using the netvend api. This article details many features which can now be added to this simple base, many of which showcase netvend's particular strengths and utility. Note that all of these features work not only among users of this coinflow client specifically, but also among any netvend client that chooses to post and query for data in similar ways. Most of these features can be added independently from one another. If you see anything you'd like to help with, send an email to syriven@gmail.com, and I'll gladly answer any questions you have and help however I can! Encrypted Whispers Although this feature isn't exactly groundbreaking, it is highly demanded, and in this case fairly easy to implement in a user-friendly way. Partially this is because all posts are cryptographically signed on netvend by their user's agent, allowing clients to quickly communicate encryption pubkeys securely and easily. To implement encrypted whispers, two commands would have to be added: /postwhisperpubkey and /whisper. /postwhisperpubkey would simply generate an asymmetric encryption keypair, save the private key, and post the public key to netvend. By attaching a specific prefix, we can make it easy for other clients to find. whisper_pubkey_prefix = "wpubkey:" ... response = agent.post(whisper_pubkey_prefix+pubkey) /whisper would first search netvend for the recipient's whisper pubkey, then encrypt the message using the pubkey found (or spit out an error if the recipient hasn't yet posted one). Then it would encrypt and post the message, and send a tip referencing the post to the recipient. query = """ SELECT data FROM posts WHERE address = '""" + recipient_address + """' AND data LIKE '""" + whisper_pubkey_prefix + """%' ORDER BY post_id DESC LIMIT 1 """ response = agent.query(query) rows = response'command_result''rows' if len(rows) 0: #display an error to the user and break out data = rows00 pubkey = datalen(whisper_pubkey_prefix): encrypted_message = some_encrypt_func(pubkey, message) response = agent.post("whisper:" + encrypted_message) post_id = response'command_result' response = tip(recipient_address, 0, post_id) First, we run a query to fetch the recipient's whisper pubkey: we get the 'data' column from the 'posts' table for any rows that have our recipient as the author, and start with whisper_pubkey_prefix. By ordering it by descending post_id and limiting it to 1 row, we'll get latest posted pubkey. Then we simply use the fetched pubkey to encrypt the message, post it with a 'whisper:' prefix, and send a tip to the recipient referencing the post. In this case, the tip function is used less as a money-transmitting tool, and more of an agent-to-agent notification. Finally, the feed can include any found whispers by running something like: query = """ SELECT posts.address, posts.data, tips.value, posts.ts FROM tips JOIN posts ON tips.post_id = posts.post_id WHERE tips.to_address = '""" + agent.get_address() + """' AND posts.data LIKE 'whisper:%' """ response = agent.query(query) rows = response'command_result''rows' As you can see, we fetch various columns from a JOIN of the posts and tips table, in which we are the recipient and the post begins with 'whisper:'. Now, rows contains a list of encrypted messages sent to us from other users. This can now be saved/displayed to the user however the programmer likes. calculating and displaying "trust levels" based on tipping history By iterating through agents the user has tipped, and agents those agents have tipped, etc., we can calculate the relative trust of any agents within N degrees of tip separation. With single-click, sub-satoshi tips, this will offer a very rich and dependable way of prioritizing valuable content and users over spam, and a quick way of algorithmically measuring the amount of trust that should be placed in any other agent. Put in a different way, this feature will allow users to quickly judge whether a vendor of some service can be trusted, and this determination is based on the opinions of the agents that the user has already personally approved of. The algorithm would start by querying for an initial pool of agents: those the user's agent has tipped most. It would use the ratio of tips sent to determine the relative level of trust of all of these identities. Then it would repeat the process, but use the tips sent from the pool fetched in the first step, which would effectively measure "who is trusted by those you trust directly". The algorithm would iterate N times, each time measuring the trust of those who are one degree further separated from you via tips. At each iteration, the relative trust value of each agent would determine the weight given to that agent's tips--in other words, the agents you tip the most will always determine most of your feed, regardless of whether those agents actually tip the most often. Assuming the tipping history is rich enough, this would allow any honest vendor to easily "break in" to a trusted network of users. For example, if I want to tutor someone in math, I can offer it for free at first. If anyone likes it enough to tip it, I'll have moved into the networks of trust of anyone who has, in turn, tipped or followed them. With each tip or payment sent to my tutoring service agent, its trust becomes stronger. This effect can be magnified by adding friends' sent tips to the feed of the client: when someone tips or pays for my tutoring service, that action shows up on the feeds of agents who've followed or tipped them. On the other hand, spam has very little chance of getting into the networks of any "real" user. Think of it this way: there's no chance you'll tip spam, there's almost no chance that those you've tipped will tip spam, and so on. When this trust data has been gathered, the application can handle this information in two ways: At first, this should do something simple like highlight trusted agents, maybe making the hue indicate something about the nature of the trust (first-degree trust is green, N-degree trust is blue, etc.). When the network has reached a wider community, however, this can be used to filter out any agents that aren't found within N degrees of separation. This may seem extremely exclusive, but at that point there will be tools to allow users to easily break into the network of trust (see How a new user can easily gain trust). (article still in progress)